c. フィーチャーチームモデル
https://scrapbox.io/files/64953e3771e50c001b08d1e7.png
フィーチャーチームは、顧客価値を中心に構成されている
各チームは顧客ドメインの 1 種類以上の機能を専門としている（機能の種類には、診断、債権取引、管理などがありえる）
フィーチャーチームの利点
明確な機能の所有権
table:明確な機能の所有権
メリット 代償
機能全体を既存システムで機能させる責任を持つ人が明らかになる（フィーチャーチームが持つ） 同時に同じコンポーネントを触るチームが増える
この代償の回避方法
モダンな技術的手法を導入することによる設計/コードの改善
e.g. 単体テスト、徹底的なリファクタリング、継続的インテグレーション、複数チームでの設計ワークショップ、進化的設計
コンポーネントメンターとコンポーネントコミュニティーによる支援
学習の場を提供し、まだ慣れていないチームによるコンポーネント変更を支援する（参考: 13 調整と統合） 遅延を引き起こす依存関係がない
table:遅延を引き起こす依存関係がない
メリット 代償
別チームの作業を待つ必要がないため、機能要求から価値提供までの時間が短縮される 同じ機能が何度も実装される可能性がある
この代償の回避方法
顧客の言葉で話す開発組織
table:顧客の言葉で話す開発組織
メリット 代償
より目的のある作業ができる（何を、なぜ、誰のために作るのか理解できる）、顧客と開発者の間の間接的な層（アナリスト、 PdM など）を削減できる 顧客とのコミュニケーションスキルを不要と考えるエンジニアもいる
フィーチャーチームの欠点
フィーチャーチームへの移行に伴う課題は発生するが、解決可能である
開発者はシステムの多くの部分を学ぶ必要がある
多くを学ぶ必要はあるが、システム全体を知る必要があるわけではない
チーム内の人は一番得意な分野を持ち、チーム自体も専門とするエリアを持つ
50 のコンポーネントをもつシステムだったとして、そのうち 2,3 について深く知り、 10 くらいについて浅く知っているイメージ
乱雑なコード/設計につながる可能性がある
「共同責任は無責任も同じ」という考えから、コード/設計が劣化する可能性がある
技術的卓越性とモダンな技術的手法によって、これらの劣化を防ぐことができる
放っておいてもコード/設計が劣化しない場合もある
開発者は、他人にコードを見られることがわかっており、自身のエンジニアとしての評判を維持するためにさらに努力するから（参考: 13 調整と統合） 分割の方法は仕事の仕方に影響を及ぼす
コンポーネントチームでは、コンポーネント単位でのタスク分割をチームとは別の人やグループ（アーキテクト、アナリスト、仕様作成者など）が行う
フィーチャーチームではこの方法での分割は不要で、プロダクトバックログリファインメントでの分割となる